Registering network applications with an API framework

ABSTRACT

A method for registering a network application with an application programming interface (API) framework. In operation, a registrar may send a registration message that associates a namespace with the network application to the API framework. In one implementation, the namespace associated with the network application may be a uniform resource identifier. In another implementation, the registration message may specify a format of the standardized clients, a security policy, and the application resources associated with the network application.

BACKGROUND

A network application, such as a Web application, is typicallyaccessible to users via a client application. The client may beimplemented as part of, or alongside, the Web application. Alternately,the developer of the Web application can publish, or make available, anapplication programming interface (API) so that other developers cancreate clients for the Web application. Some clients are standardized toparticular formats, such as Really Simple Syndication (RSS) or ATOMSyndication (ATOM).

There are two components of an API: an abstraction component and animplementation component. The abstraction component is essentially adocument (or series of documents) that describes to a developer how towrite source code to interface with the Web application. Theimplementation component is executable code that acts as the interfacebetween clients written to the API and the Web application itself.

SUMMARY

Described herein are implementations of various technologies forregistering a network application with an application programminginterface (API) framework. In operation, a registrar may send aregistration message that associates a namespace with the networkapplication to the API framework. In one implementation, the namespaceassociated with the network application may be a uniform resourceidentifier. In another implementation, the registration message mayspecify a format of the standardized clients, a security policy, and theapplication resources associated with the network application.

The registrar may then store create, read, update, and delete (CRUD)methods for an application resource associated with the networkapplication. The CRUD methods may be configured to be invoked by arequest from the API framework. In one implementation, the request fromthe API framework may be a representational state transfer (REST) orSOAP request.

In response to receiving the registration message, the API framework maycreate an API associated with the network application. In oneimplementation, the network application may be a Web application.

The above referenced summary section is provided to introduce aselection of concepts in a simplified form that are further describedbelow in the detailed description section. The summary is not intendedto identify key features or essential features of the claimed subjectmatter, nor is it intended to be used to limit the scope of the claimedsubject matter. Furthermore, the claimed subject matter is not limitedto implementations that solve any or all disadvantages noted in any partof this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic diagram of a computing system in whichthe various technologies described herein may be incorporated andpracticed.

FIG. 2 illustrates a schematic diagram of an example application serverresource hierarchy for which the various technologies described hereinmay be incorporated and practiced.

FIG. 3 illustrates a flow chart of a method for registering a networkapplication with an application programming interface (API) framework inaccordance with one or more implementations of various techniquesdescribed herein.

DETAILED DESCRIPTION

In general, one or more implementations of various technologiesdescribed herein are directed to registering network applications withan application programming interface (API) framework. A registrar mayinitiate the registration process by sending a message that associates anamespace with the network application to the API framework. Theregistrar may store create, read, update, and delete (CRUD) methods foran application resource associated with the network application. Inresponse, the API framework may create an API associated with thenetwork application. As a result, developers may then write standardizedclients for the network application by simply using the API created bythe API framework.

Implementations of various technologies described herein may beoperational with numerous general purpose or special purpose computingsystem environments or configurations. Examples of well known computingsystems, environments, and/or configurations that may be suitable foruse with the various technologies described herein include, but are notlimited to, personal computers, server computers, hand-held or laptopdevices, multiprocessor systems, microprocessor-based systems, set topboxes, programmable consumer electronics, network PCs, minicomputers,mainframe computers, distributed computing environments that include anyof the above systems or devices, and the like.

The various technologies described herein may be implemented in thegeneral context of computer-executable instructions, such as programmodules, being executed by a computer. Generally, program modulesinclude routines, programs, objects, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The various technologies described herein may also be implementedin distributed computing environments where tasks are performed byremote processing devices that are linked through a communicationsnetwork, e.g., by hardwired links, wireless links, or combinationsthereof. In a distributed computing environment, program modules may belocated in both local and remote computer storage media including memorystorage devices.

FIG. 1 illustrates a schematic diagram of a computing system 100 inwhich the various technologies described herein may be incorporated andpracticed. The computing system 100 includes a client 102, anapplication programming interface (API) framework server 122, and anapplication server 142 remotely connected via a network 160. The network160 may be any network or collection of networks that link remotecomputers such as a local area network or a wide area network. In oneimplementation, the network 160 is the Internet. Although the client102, API framework server 122, and application server 142 may beconventional desktops or server computers, as described above, othercomputer system configurations may be used.

The client computer 102 may include a central processing unit (CPU) 104,a system memory 106 and a system bus 117 that couples various systemcomponents including the system memory 106 to the CPU 104. It should benoted that the CPU 104 may include Virtualized systems (VirtualMachines, Processors), as well as CPU Cores and Hyper-threadedprocessors within a physical CPU. Although only one CPU is illustratedin FIG. 1, it should be understood that in some implementations theclient computer 102 may include more than one CPU. The system bus 117may be any of several types of bus structures, including a memory bus ormemory controller, a peripheral bus, and a local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus also known as Mezzanine bus.

The client computer 102 may further include a storage 108, which may beconnected to the bus 117. Examples of storage 108 include a hard diskdrive for reading from and writing to a hard disk, a magnetic disk drivefor reading from and writing to a removable magnetic disk, and anoptical disk drive for reading from and writing to a removable opticaldisk, such as a CD ROM or other optical media. The storage 108 andassociated computer-readable media may provide nonvolatile storage ofcomputer-readable instructions, data structures, program modules andother data for the client computer 102.

It should be appreciated by those skilled in the art that the clientcomputer 102 may also include other types of storage 108 and associatedcomputer-readable media that may be accessed by a computer. For example,such computer-readable media may include computer storage media andcommunication media. Computer storage media may include volatile andnon-volatile, and removable and non-removable media implemented in anymethod or technology for storage of information, such ascomputer-readable instructions, data structures, program modules orother data. Computer storage media may further include RAM, ROM,erasable programmable read-only memory (EPROM), electrically erasableprogrammable read-only memory (EEPROM), flash memory or other solidstate memory technology, CD-ROM, digital versatile disks (DVD), or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bythe client computer 102. Communication media may embody computerreadable instructions, data structures, program modules or other data ina modulated data signal, such as a carrier wave or other transportmechanism and may include any information delivery media. The term“modulated data signal” may mean a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia may include wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media. Combinations of any of the above may also be includedwithin the scope of computer readable media.

A number of program modules may be stored in memory 106, including anoperating system 112, a standardized client 114, and a development kit116. The operating system 112 may be any suitable operating system thatmay control the operation of a networked personal or server computer,such as Windows® Vista, Mac OS® X, Unix-variants (e.g., Linux® andBSD®), and the like. The standardized client 114 may be software thatpresents information about a Web application 155 and resources 156 (bothstored on application server 142) to a user, where the client 114 isstandardized to a particular format. Examples of standardized formatsinclude really simple syndication (RSS), ATOM Syndication, ATOMPublishing Protocol (APP), JavaScript Object Notation (JSON), extensiblemarkup language (XML), and binary XML. In one implementation, thestandardized client 114 is an RSS reader.

Typically, a software engineer downloads a copy of the development kit116 from the API framework server 122 to the client 102. The developmentkit 116 may include a set of development tools that enables the softwareengineer to create the standardized client 114. The development toolsmay include code editors, debugging aids, and other utilities oftenpresented in an integrated development environment. Using thedevelopment kit 116, the software engineer may create source code (notshown), compile the source code, and link the compiled code to generatethe standardized client 114.

In one implementation, the development kit 116 may communicate with anAPI framework 135 (stored on the API framework server 122) to determinesome of the parameters required to access the Web application 155 andassociated resources 156. The development kit 116 may present theparameters to the software engineer. Accordingly, the software engineermay incorporate the requisite parameters into the source code for thestandardized client 114.

A user may enter commands and information into the client computer 102through an input device 118. Examples of input devices 118 includekeyboards, pointing devices, microphones, joysticks, game pads,satellite dishes, scanners, or the like. These and other input devicesmay be connected to the CPU 104 through the system bus 117. A user mayreceive information from the client computer 102 via an output device119. Examples of output devices 119 include displays, speakers,printers, and fax machines.

The client computer 102 may be connected to the network 160 through anetwork interface 110. It will be appreciated that the networkconnections shown are exemplary and other means of establishing acommunications link between the computers may be used.

The API framework server 122 and application server 142 may be similarlyconstructed as the client computer 102. The API framework server 122 maycontain a CPU 124, system memory 126, storage 128, and network interface130. Similarly, the application server 142 may contain a CPU 144, systemmemory 146, storage 148, and network interface 150.

At the application server 142, the system memory 146 may include anoperating system 152 and a registrar 153. The registrar 153 may besoftware that makes the Web application 155 accessible to thestandardized client 114 via the API framework 135. In oneimplementation, the registrar 153 may send a registration message to theAPI framework 135. In response, the API framework 135 may create an API138 for the Web application 155. Additionally, the registrar 153 maystore resource methods 154 on the application server 142. The resourcemethods 154, when invoked, may access/update the resources 156associated with the Web application 155. The registrar 153 will bedescribed in greater detail in the description of FIG. 3.

The storage 148 may include the Web application 155, resource methods154 and resources 156. The Web application 155 may be software forsharing and managing resources 156 for users of clients 102. Examples ofWeb applications 155 include Weblogs (blogs), discussion boards, e-mailprograms, and software for sharing media, such as photographs. In oneimplementation, the Web application 155 may be a Web service.

It should be noted that the Web application 155 is merely a specificexample of a network application, and that any application accessiblevia a hypertext transfer protocol (HTTP) or HTTP over Secure SocketLayer (HTTPS) may be used in various implementations described herein.

Each resource 156 may be associated with and managed by a particular Webapplication 155. The resources 156 managed in the example Webapplications include blog or discussion board posts, e-mails, e-mailfolders, and the photographs or other media shared. Those skilled in theart recognize that a wide array of Web applications 155 and resources156 are possible, and these examples are provided for purposes ofillustration and are not intended to be limiting.

Each resource method 154 may perform one create, read, update, or delete(CRUD) operation for one or more of the resources 156 of an associatedWeb application 155. Resource methods 154 on the application server 142may be invoked by the API framework 135 based on the registered API 138for the associated Web application 155. The API framework 135 and API138 will be described in more detail in the paragraphs below withreference to the API framework server 122.

In one implementation, the API framework 135 may invoke the resourcemethods 154 using a representational state transfer (REST) request tothe Web application 155. REST is an architectural methodology fordistributed hypermedia systems such as the World Wide Web. RESTdescribes any simple interface that transmits domain-specific data overhypertext transfer protocol (HTTP) without an additional messaginglayer.

Typically, a REST request uses the standard GET, POST, PUT, DELETEsemantics of HTTP. It should be noted that other REST operations, suchas HEAD (an optimized GET operation), and yet to be developed operationsmay be accommodated in various implementations described herein.Further, REST is merely one example of a methodology for sendingapplication resource requests from the API framework server 122 to theapplication server 142. It should be noted that othermethodologies/protocols, such as SOAP or binary may be used for requeststo invoke resource methods 154 in various implementations describedherein.

Referring now to the API framework server 122, the system memory 126 mayinclude an operating system 132 and the API framework 135. The APIframework 135 may include one or more APIs 138. The APIs 138 may specifyWeb applications 155 available to standardized clients via the APIframework 135. Further, each API 138 may specify how the standardizedclient 114 may interact with the Web application 155 and associatedresources 156.

The API framework 135 may be software that provides access to the Webapplication 155 for the standardized client 114. In one implementation,the API framework 135 may initiate requests for access to the Webapplication 155 and/or resources 156 in response to hypertext transferprotocol (HTTP) requests from the standardized client 114. Additionally,the API framework 135 may create the API 138 for the Web application 155in response to a registration request from the registrar 153.

In another implementation, the API framework 135 may invoke resourcemethods 154 corresponding to the request from the standardized client114 and receive a response from the Web application 155. Further, theAPI framework 135 may translate the response from the Web application155 into the format used by the standardized client 114 and send thetranslated response to the standardized client 114.

While the computing system 100 illustrates the API framework server 122and application server 142 as separate computers, it should beunderstood that in some implementations, the functionalities performedby the API framework server 122 and the application server 142 may beperformed by a single computer. For example, the Web application 155,resource methods 154, and resources 156 may be alternatively stored inthe storage 128.

FIG. 2 illustrates a schematic diagram 200 of a resource hierarchy on aWeb application server 242 for which the various technologies describedherein may be incorporated and practiced. The resource hierarchyrepresents a namespace taxonomy by which the standardized client 114identifies the Web application 155 and the resource 156 for a particularrequest. For example, the standardized client 114 may issue a requestthat specifies a centralized domain for the application programminginterface (API) framework server 122 alongside the Web application 155and the resource 156.

As shown, a Web application server 242 may have more than one Webapplication 255. Some examples of Web applications 255 include anaddress book 210, a photo sharing application 220, and a blogsapplication 230. Each application 255 has access to different types ofresources 256. In one implementation, resources 256 can include data 260and organizational-type resources, such as libraries 258. For example,the photo sharing application 220 may organize photos 224 (andassociated comments 226) into albums 222. Similarly, the blogsapplication 230 may organize posts 234 and comments 236 into differentblogs 232.

In another implementation, an application, such as the address book 210,may access data 260 without the use of libraries 258. For example, theaddress book 210 may access data 260, such as a person 214, by usingother data 260 available to the address book 210, such as a category212, and a person reference 216. In such a scenario, the personreference 216 may represent a pointer to each person 214 in a particularcategory 212.

In a system that publishes Web applications 155 to standardized clients114, resource methods 154 may be stored on the application server 142for each resource 256. Accordingly, in the example shown, resourcemethods 154 (one each for CREATE, READ, UPDATE, and DELETE) are storedfor the album 222 and blog 232 libraries. The resource methods 154 arealso stored for each of the category 212, person reference 216, person214, photo 224, comments 226, post 234, and comments 236 data.

FIG. 3 illustrates a flow chart of a method 300 for registering anetwork application with an application programming interface (API)framework in accordance with one or more implementations of varioustechniques described herein. In one implementation, the method 300 maybe performed by the registrar 153.

As shown, the method 300 begins at step 305 when the registrar 153 sendsa registration message for each Web application 155 to the API framework135. The registration message may include a namespace, the uniformresource identifier (URI) of the web application 155, and the formatsfor standardized clients 114 to which the Web application 155 is to bemade accessible. Additionally, the registration message may specify theresources 156 associated with the registered Web application 155.

The namespace is an identifier by which the API framework 135 associatesclient requests for the Web application 155 with the Web application155. The URI identifies the location of the web application 155. Theformats may include any standardized format such as really simplesyndication (RSS), ATOM Syndication, JavaScript Object Notation,extensible markup language (XML), or binary XML. The formats describedherein are mere examples and are not intended to be limiting. Thoseskilled in the art appreciate that other formats, known or yet to bedeveloped, may be used in various implementations described herein.

In one implementation, the registration message may include a securitypolicy. The security policy may specify one or more rules forrestricting client access to the Web application 155 and/or theassociated resources 156. The security policy may be recorded in the API138.

At step 310, the registrar 153 may determine all the resources 156associated with the Web application 155 for which the registrationmessage is sent. For example, all the resources 256 associated with thephoto sharing application 220 include the album library 222, the photodata 224, and the comment data 226.

Steps 315-325 may be repeated for each resource 156 associated with theWeb application 155. At step 320, the registrar 153 may create resourcemethods 154 for the resource 156. The resource methods 154 may includecreate, read, update, and delete (CRUD) methods for each resource 156.At step 325, the registrar 153 may store the resource methods 154 on theapplication server 142. As such, in response to client requests, the APIframework 135 may create, read, update and delete resources 156 byinvoking the stored resource methods 154.

Advantageously, developers of standardized clients 114 may consumenumerous Web applications 155 registered in a centralized API framework135. Without the centralized APIs 138 provided by the API framework 135,developers would have to develop clients to consume applicationsaccording to the varying models of APIs provided by the individual Webapplications.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A method for registering a network applicationcomprising a Web application with an application programming interface(API) framework, comprising: sending, from a registrar, to the APIframework a registration message that associates a namespace comprisinga universal resource identifier (URI) with the network application andthat specifies an application resource associated with the networkapplication, the application resource comprising at least one of a blogpost, a discussion board post, or a photo, the registration messageconfigured to enable the API framework to create an API associated withthe network application in response to receiving the registrationmessage, the registration message comprising: a format of a standardizedclient; and a security policy for at least one of the networkapplication or the application resource, the security policy specifyinga rule for restricting access, by the standardized client, to at leastone of the network application or the application resource; and storing,by the registrar, create, read, update, and delete (CRUD) methods forthe application resource associated with the network application, theCRUD methods configured to be invoked by a request comprising at leastone of a representational state transfer (REST) request or a SOAPrequest from the API framework, the request from the API frameworkinitiated in response to a hypertext transfer protocol request from thestandardized client.
 2. The method of claim 1, the format comprisingReally Simple Syndication (RSS).
 3. The method of claim 1, the formatcomprising ATOM Syndication.
 4. The method of claim 1, the registrarcomprised in an application server.
 5. The method of claim 1, the APIframework comprised in an API framework server.
 6. The method of claim1, the registrar comprised in an application server that is connectedvia a network to an API framework server comprising the API framework.7. The method of claim 1, the application resource and the networkapplication comprised in an application server.
 8. The method of claim7, the application server comprising the registrar.
 9. The method ofclaim 1, comprising at least one of: determining the applicationresource associated with the network application; or creating the CRUDmethods.
 10. The method of claim 6, the standardized client connected toat least one of the application server or the API framework server viathe network.
 11. A computer-readable storage medium comprisinginstructions that when executed via a microprocessor perform a methodcomprising: sending, from a registrar, to an application programminginterface (API) framework a registration message that associates anamespace comprising a universal resource identifier (URI) with a Webapplication and that specifies an application resource associated withthe Web application, the application resource comprising at least one ofa blog post, a discussion board post, or a photo, the registrationmessage configured to enable the API framework to create an APIassociated with the Web application in response to receiving theregistration message, the registration message comprising: a format of astandardized client; and a security policy for at least one of the Webapplication or the application resource, the security policy specifyinga rule for restricting access, by the standardized client, to at leastone of the Web application or the application resource; and storing, bythe registrar, create, read, update, and delete (CRUD) methods for theapplication resource associated with the Web application, the CRUDmethods configured to be invoked by a request comprising at least one ofa representational state transfer (REST) request or a SOAP request fromthe API framework, the request from the API framework initiated inresponse to a hypertext transfer protocol request from the standardizedclient.
 12. The computer-readable storage medium of claim 11, theregistrar comprised in an application server.
 13. The computer-readablestorage medium of claim 11, the API framework comprised in an APIframework server.
 14. The computer-readable storage medium of claim 11,the registrar comprised in an application server that is connected via anetwork to an API framework server comprising the API framework.
 15. Thecomputer-readable storage medium of claim 14, the standardized clientconnected to at least one of the application server or the API frameworkserver via the network.
 16. The computer-readable storage medium ofclaim 11, the application resource and the Web application comprised inan application server.
 17. The computer-readable storage medium of claim16, the application server comprising the registrar.
 18. A computersystem, comprising: a first microprocessor; and a first memorycomprising program instructions executable by the first microprocessorto: send, from a registrar, to an application programming interface(API) framework a registration message that associates a namespacecomprising a universal resource identifier (URI) with a networkapplication and that specifies an application resource associated withthe network application, the application resource comprising at leastone of a blog post, a discussion board post, or a photo, theregistration message configured to enable the API framework to create anAPI associated with the network application in response to receiving theregistration message, the registration message comprising: a format of aclient; and a security policy for at least one of the networkapplication or the application resource, the security policy specifyinga rule for restricting access, by the client, to at least one of thenetwork application or the application resource; and store, by theregistrar, one or more create, read, update, and delete (CRUD) methodsfor the application resource associated with the network application,the CRUD methods configured to be invoked by a request comprising atleast one of a representational state transfer (REST) request or a SOAPrequest from the API framework, the request from the API frameworkinitiated in response to a hypertext transfer protocol request from theclient.
 19. The computer system of claim 18, the registrar, theapplication resource and the network application comprised in anapplication server.
 20. The computer system of claim 19, the applicationserver connected via a network to an API framework server comprising theAPI framework.